The attached article highlights the main points faced by
the Domino Administrators in migrating users across Domino domains and
explains in detail the method which will help them in achieving this. It
provides detailed instructions for creating the required server
configurations.
Table of Contents
Table of Contents
- Creating AdminP Cross Domain Configuration document for Inbound & Outbound request for necessary capabilities for Migrating users.
- Configuring Connection documents.
- Configuring Adjacent Domain documents.
- Copying Certifiers documents.
- Certifying Organization Certifier & subsequent Certifiers vice-versa.
- Providing Administrator & Servers proper access for Migration.
- Rename Users who requires migration.
- Creating Replicas for Migrating Users.
- Moving Migrated Person Documents.
- Creating Agents & Necessary Buttons to populate the changes for the Migrated Users.
- Other elements that you might take into consideration
Process for Migrating Users Across Domino Domains
Type of Submission: Article
Title: Process For Migrating Users Across Domino Domains.
Keywords: Lotus Domino, AdminP Process
Abstract: Administration process is a program that
automates many routine administrative tasks, such as Deleting User,
Moving users between Servers and many more. We can also use the AdminP
process to migrate a user from one Domino Domain to another Domino
Domain. This Article explains the various steps involved to accomplish
the same & benefits for doing the same.
Introduction
We are using two fictitious Domino Domains LTSO(Source)
& ITSO(Target) to demonstrate the process of migrating users using
AdminP process to move a user “Anshul Gupta/IT Services/LTSO” from
Domino Domain “LTSO” to “Anshul Gupta/ITSO IT Services” to Domino Domain
“ITSO”.
Here is a brief summary of the steps involved & the details follow later:
1.
Creating Administration Process - Cross Domain Request Configuration
Inbound (ITSO Domain) & Outbound (LTSO Domain) documents to allow
the necessary capabilities between Source (LTSO) and Target Domino
Domain (ITSO).
2. Creating Connection Documents between Source (LTSO) Domain Server and Target Domain (ITSO) Server. These will Facilitate Replica Creation of the Mail File of the User “Anshul Gupta” moving from Source (LTSO) and Target Domino Domain (ITSO).
3. Configure Adjacent Domain document in Source (LTSO) so that the email to the "Administration Requests@" gets generated and delivered to the Target Domino Domain (ITSO).
4. Copying the Target Domino Domain (ITSO) Certifier Document (“/ITSO IT Service”) & Target Domino Domain (ITSO) Server Document in the Source (LTSO) Domino Domain Server.
5. Cross Certifying the Source (LTSO) Domino Domain and Target Domino Domain (ITSO) Servers and Administrator vice-versa. To facilitate smooth Cross Domain server access & replication.
6. Rename users with “Request Move to New Certifier” in the Source (LTSO) Domino Domain & completing all Administration Process involved with it. In this example we will rename user “Anshul Gupta/IT Services/LTSO” to “Anshul Gupta/ITSO IT Services” in the Source (LTSO) Domino Domain.
7. After User move to new certifier process completes, We will use AdminP to create new replicas of the mail files of the moved Users “Anshul Gupta” to the Target Domino Domain (ITSO) Domino Domain Servers.
8. Manually copy Person Document from the Source Domino Domain (LTSO) to Target Domino Domain (ITSO) Domino Directory.
9. Create an Agent on the Target Domino Domain Server’s Domino Directory to Populate the Target Domino Domain field in the Person Document. As Well write an agent which can populate the new Server Information and Domain Information in the Location document of the end user
2. Creating Connection Documents between Source (LTSO) Domain Server and Target Domain (ITSO) Server. These will Facilitate Replica Creation of the Mail File of the User “Anshul Gupta” moving from Source (LTSO) and Target Domino Domain (ITSO).
3. Configure Adjacent Domain document in Source (LTSO) so that the email to the "Administration Requests@" gets generated and delivered to the Target Domino Domain (ITSO).
4. Copying the Target Domino Domain (ITSO) Certifier Document (“/ITSO IT Service”) & Target Domino Domain (ITSO) Server Document in the Source (LTSO) Domino Domain Server.
5. Cross Certifying the Source (LTSO) Domino Domain and Target Domino Domain (ITSO) Servers and Administrator vice-versa. To facilitate smooth Cross Domain server access & replication.
6. Rename users with “Request Move to New Certifier” in the Source (LTSO) Domino Domain & completing all Administration Process involved with it. In this example we will rename user “Anshul Gupta/IT Services/LTSO” to “Anshul Gupta/ITSO IT Services” in the Source (LTSO) Domino Domain.
7. After User move to new certifier process completes, We will use AdminP to create new replicas of the mail files of the moved Users “Anshul Gupta” to the Target Domino Domain (ITSO) Domino Domain Servers.
8. Manually copy Person Document from the Source Domino Domain (LTSO) to Target Domino Domain (ITSO) Domino Directory.
9. Create an Agent on the Target Domino Domain Server’s Domino Directory to Populate the Target Domino Domain field in the Person Document. As Well write an agent which can populate the new Server Information and Domain Information in the Location document of the end user
10. Other elements that you might take into consideration.
Process in Detail
Step
|
Action
|
1(a)
|
Creating
Administration Process - Cross Domain Request Configuration Inbound
(ITSO Domain) & Outbound (LTSO Domain) documents to allow the
necessary capabilities between Source (LTSO) and Target Domino Domain
(ITSO).
|
In the Domino Administration Client, Select the Server Tab
|
|
Select the Analysis Tab
|
|
In Administration Request
|
|
Go to Cross Domain Configuration
|
|
Click on Add Configuration
|
|
& Create Outbound Configuration in LTSO Domain for ITSO Domain, as Shown in Figure 1 & 2
|
|
Figure 1
|
![]() |
Figure 2
|
![]() |
Step
|
Action
|
|
1(b)
|
In Similar
Fashion Create a Inbound Cross Domain Configuration Document in ITSO
Domain for LTSO Domain as Shown in Figure 3 & 4
|
|
Figure 3
|
![]() |
|
Figure 4
|
![]() |
Step
|
Action
|
2
|
Create a
Connection document between LTSO & ITSO Domino Domains, the Source
and the Target Domino Domains. To Facilitate Replica Creation of the
Mail File of the user moving from Source to the Target Domino Domain. As
Shown in Figure 5.
|
Figure 5
|
![]() |
Step
|
Action
|
3
|
Create a Adjacent Domain Document, to facilitate email to the "Administration Requests@" gets generated and delivered to the target domain. As Shown in Figure 6
|
Here we are creating a Adjacent Domain Document in LTSO Domino Domain for ITSO Domino Domain.
|
|
Figure 6
|
![]() |
Step
|
Action
|
4
|
Copying
The Target Certifier Document & Source Server Document in the Source
Domino Domain Server. (See Figure 7 & 8)( “ITSO IT Services”
Certifier document from ITSO to LTSO Domino Directory)
|
Figure 7
|
![]() |
Figure 8
|
![]() |
Step
|
Action
|
5
|
Cross
Certifying the Source (LTSO) Domino Domain and Target Domino Domain
(ITSO) Servers and Administrator vice-versa. To facilitate smooth Cross
Domain server access & replication.
|
Cross Certifying the Source and Target Servers and Administrators for access.
|
|
Cross Certify ITSO Server & ITSO Administrator in LTSO Domino Domain & vice-versa, See Figure 9 & 10.
|
|
Figure 9
|
![]() |
Figure 10
|
![]() |
Step
|
Action
|
6
|
Rename
users with “Request Move to New Certifier” in the Source Domino Domain
& completing all Administration Process involved with it.
Here we are Renaming User Anshul Gupta/IT Services/LTSO to Anshul
Gupta/ITSO IT Services/ITSO. See Figure 11,12,13,14,15,16,17,18 &
19.
|
Figure 11
|
Selecting the User & Selecting the Option “Rename User” & Selecting “Request Move to New Certifier”
![]() |
Figure 12
|
![]() |
Figure 13
|
![]() |
Figure 14
|
![]() |
Figure 15
|
![]() |
Figure 16
|
![]() |
Figure 17
|
![]() |
Figure 18
|
![]() |
Figure 19
|
![]() |
Step
|
A Action
|
7
|
After User
move to new certifier process completes, have adminp create new
replicas of the mail files of these moved Users to the Target Domino
Domain Servers.
In The current scenario we are moving the renamed user Anshul Gupta/ITSO It Services/ITSO mail File to the Target Domain i.e. ITSO. This Request also looks for the Cross Domain AdminP Configuration document created in the Beginning in Source LTSO (Outbound) & Target ITSO (Inbound) Domain. See Figure 20 & 21. |
Figure 20
|
![]() |
Figure 21
|
![]() |
Step
|
Action
|
8
|
Manually copy Person Document from the Source Domino Domain to Target Domino Domain Domino Directory.
Here We are Copying Anshul Gupta/ITSO IT Services/ITSO into ITSO Domino Directory, as the User has been Successfully moved to a New Certifier. See Figure 22. |
Figure 22
|
![]() |
Step
|
Action
|
9
|
Create and
Agent on the Target Domino Domain Server’s Domino Directory to Populate
the Target Domino Domain field in the Person Document. As Well write an
agent which can populate the new Server Information and Domain
Information in the Location document of the end user. See Figure 23
& 24 & 25.
|
Figure 23
|
![]() |
Figure 24
|
![]() |
Figure 25
|
![]() |
10. Other elements that you might take into consideration:
In the source domain the user's ID Files were uploaded into the vault. Now, after the users have been migrated to the new target domain, you might expect that the user's ID Files will be harvested automatically on the new target domain's vault without any administrative intervention.
After applying, to the
migrated users, the effective policy, that has a Security Settings
document specifying the vault name on the target domain. You experience
that the user's ID files are not harvested into the target domain's
vault straightaway.
The users are able to work around this issue with one of these 2 actions:
1. By switching the user.id to itself.
2. By deleting the notes.ini parameters referencing the old id vault server in the client's notes.ini.
Additionally the following SPRs have been identified in the ID Vault area that are related :
SPR # NEKO88FT7H: If user has a nonexistent server specified in notes.ini var IDVaultLastServer, might not connect with vault server
LO61997: IF USER HAS A NONEXISTENT SERVER SPECIFIED IN NOTES.INI VAR IDVA ULTLASTSERVER, THE USER MAY NOT CONNECT WITH THE VAULT SERVER
SPR # NEKO9CRKX6: The notes.ini last ID vault server accessed value should be flushed every 2 weeks.
IDVaultLastFlushTime
https://www-10.lotus.com